Software that runs on a Central Processing Unit (CPU) in order to fulfill certain functionality of the host device often changes over time. The changes may result from the need to correct software bugs, adapt to evolving technologies, or add new features to the host device. In particular, embedded software in mobile wireless devices like cellular telephones often includes more bugs than other portable devices or processing systems and generally requires more frequent updates to add new features to the device.
Software includes one or more files which can be in the form of American Standard Code for Information Interchange (ASCII) plain text files or binary code. Software files can be divided into smaller units that are often referred to as components or modules. In the current art, a UNIX platform or Personal Computer (PC) includes multiple software components, and each of the software components is managed and updated independently through a file system supported by a corresponding Operating System (OS). Information used to update software files or software components hosted on UNIX platforms or PCs can be transferred through the Internet or loaded from a secondary storage medium such as a floppy disk, a compact disk read-only memory (CD-ROM), or a compact flash card.
In contrast, in most mobile wireless devices, a real-time OS (RTOS) is typically used in which all software components are linked as a single large file. Further, no file system support is typically provided in these mobile wireless devices. In addition, the single large file needs to be preloaded, or embedded, into the device using a slow communication link like a radio, infrared, or serial link.
Obstacles to the update of large files via slow communication links include the time of delivering the updated file to the device. In cases where a difference file is transferred to the device hosting the files targeted for update/revision, this time includes both the communication time to transfer the difference file and the time used by the receiving device to process the difference file and update/revise the targeted files, referred to herein as the host device processing time. While use of a delta file to transfer updated software file or software component information significantly reduces the communication time, as described in the Related Applications, reduction of the host device processing time is dictated at least in part by the host device architecture.
The host device can be any of a number of processor-based devices, including cellular telephones and other mobile communication devices, personal digital assistants (PDAs), and personal computers. Using cellular telephones as an example, the typical cellular telephone architecture includes flash read-only memory (ROM), referred to herein as flash ROM or flash memory, and an RTOS. Both the flash memory and the RTOS potentially introduce obstacles to the goal of reducing the host device processing time.
The problem that arises with respect to the flash memory in reducing the host device processing time involves the manner with which writes are performed to flash memory. Flash memory is allocated in units which are often referred to as blocks, sectors, or segments, each of which includes numerous bytes. A write (or rewrite) to the typical flash memory requires erasing and writing (or rewriting) an entire unit, meaning that single bits or bytes can not be written (or rewritten). Therefore the update or revision of a byte stored in flash memory requires erasing and rewriting the entire unit in which the byte is stored. Thus, the time required to update or revise files stored in flash memory is typically greater than that required to update or revise files stored in other types of storage or memory in which single bytes can be written (or rewritten).
The problem that arises with respect to the RTOS in reducing the host device processing time involves the manner in which host device software programs are organized and managed. The RTOS of typical cellular telephones does not support file management and dynamic address resolution for function calls at runtime. Therefore, all embedded software components or programs of the cellular telephone are linked into a single, large host program, and a function within the host program is called from any part of the host program directly through a precompiled start address of the function. Thus, in contrast to a typical computer OS in which file management and dynamic address resolution for function calls are supported, the typical cellular telephone RTOS does not have the capability to manage multiple software components as separate files and support the function calls from one of the software components to another via runtime calling address resolution. Consequently, the host program of a system including an RTOS manages a single, large program and uses static addressing to directly access functions of the program.
This typical device architecture can lead to a problem when updating and revising software components because when the revision or update results in changes in host program size there is a resultant change in the start addresses of the software components that follow the updated/revised software component in the host program. This change in the start address of a software component results in a need to update the corresponding calling addresses in the host program and the instruction/data addresses within the software component. This can be expensive in terms of processing time. Thus, host device processing time associated with embedded software updates/revisions is due in large part to the inefficient rewriting of data to flash memory and the fact that a small change to embedded software at the source code level can result in a large change to the embedded software at the binary code level.
In the drawings, the same reference numbers identify identical or substantially similar elements or acts. To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the Figure number in which that element is first introduced (e.g., element 130 is first introduced and discussed with respect to FIG. 1).
Unless described otherwise below, the construction and operation of the various blocks and structures shown in the Figures are of conventional design. As a result, such blocks need not be described in further detail herein, because they will be understood by those skilled in the relevant art. Such further detail is omitted for brevity and so as not to obscure the detailed description of the invention. Any modifications necessary to the Figures can be readily made by one skilled in the relevant art based on the detailed description provided herein.